Managing Security Within the Database Engine : Creating SQL Server Principals

Creating SQL Server Principals

This section will discuss the server-level principals provided for you in SQL Server 2008. Once again, those principals are SQL Server logins and SQL Server roles. We also will touch on user creation for certificates, asymmetric keys, credentials, and Windows principals.

1. Creating Logins for SQL Server

SQL Server 2008 supports both Windows and SQL Server authentication. SQL Server authentication does the username and password validation for users attempting to gain access to SQL Server, while Windows handles the user validation for Windows-authenticated users. In order to use SQL Server authentication, you must configure your instance of SQL Server to utilize Mixed Mode authentication. Mixed Mode authentication means that the instance will support both Windows authentication and SQL Server authentication. While you can configure SQL Server to enable only Windows authentication, there is no way to enable SQL Server to use only SQL Server authentication without allowing Windows authentication as well.

Creating SQL Server logins using T-SQL follows the same basic syntax as credentials, certificates, asymmetric keys, Windows principals, and SQL Server-authenticated logins. The following syntax in Listing 8-1 shows you how to create SQL Server logins.

Example 1. Syntax for Creating SQL Server Logins

CREATE LOGIN loginName {WITH PASSWORD OPTIONS, Additional Options
| FROM SOURCE}

When creating a SQL Server login, you have to specify the login name, and depending on the type of SQL Server login you are creating, specify password options or another source with which to associate the username. The available password options allow you to supply a password in standard text or a hash value. If you supply a password in standard text, then SQL Server will convert the password to hash before storing it within the database. So don't worry about your password being compromised if you create an account with a password in standard text.

The password options available to you when creating SQL Server logins are as follows:

• MUST_CHANGE: Specifies that users must change their password when they login.

• CHECK_EXPIRATION: Determines if the password expiration policy is enforced. The default value is OFF.

• CHECK_POLICY: Specifies if the Windows policies of the computer/server running SQL Server are enforced on the login. The default value is ON.

• CREDENTIAL: Identifies the name of the credential to associate to the login.

• DEFAULT_DATABASE: Specifies the default database for the new login. If you do not specify the default database parameter, SQL Server will assign the master database as the default database for the login.

• Default_Language: Specifies the default language for the new login. If you do not supply the default language parameter, SQL Server will use the default language for the instance of SQL Server.

• SID: Allows you to specify the uniqueidentifier that will be assigned to the newly created login. SQL Server will assign a random uniqueidentifier if you do not supply this parameter in the Create Login statement. The SID option is only valid for SQL Server logins.

The available sources in the FROM SOURCE clause are certificates, asymmetric keys and Windows. We will discuss associating SQL Server logins to certificates and asymmetric keys in the upcoming section "Associating Logins with Certificates and Asymmetric Keys." We will also discuss creating SQL Server logins for Windows principals in the next section.

2. Creating SQL Server Logins for Windows Principals

SQL Server 2008 permits Windows principals, local Windows users, or domain groups and users to gain access to SQL Server without resupplying a password. In order for Windows principals to access SQL Server, SQL Server uses Windows to confirm the identity of the user. Windows authentication is more secure and is the default authentication method for SQL Server. We recommend using Windows authentication whenever possible.

Creating Windows users and groups is outside of the scope of this book. However, after the creation of a Windows principal, granting access to that user within SQL Server is not complex. Using the syntax from Listing 8-1, in order to create a SQL Server user for a Windows user, you specify the SQL Server login name that you want to create, specify that the source is Windows, and then define the Windows options. The available Windows options allow you to define the default database and default languages if you want. The following code example creates a SQL Server login for a Windows principal.

USE MASTER
GO

CREATE LOGIN [mediacenter\sql] FROM WINDOWS WITH DEFAULT_DATABASE =_
AdventureWorks2008;
GO

3. Creating SQL Server-Authenticated Logins

When creating SQL Server-authenticated logins, the usernames and passwords are stored within the database. Unlike Windows authentication, users have to supply their usernames and passwords to log in to SQL Server.

To create a SQL Server-authenticated login using the syntax in Listing 8-1, specify the login name and the password. Remember, you can provide a hash password or a standard text password. If you are creating a password for a person, you may want to utilize the MUST_CHANGE option. That way, you can provide the user with a simple password like Abc123#@ and require them to change it when they login. Finally, determine the default database, the default language, and whether you want the password policy and password expiration enabled. In order to enable password expiration, then you must enable the password policy. Review the following SQL Server script to create a standard SQL Server login.

USE MASTER
GO

CREATE LOGIN apressSecurity WITH PASSWORD = 'P@ssw0rd!' ,CHECK_POLICY_
= ON, CHECK_EXPIRATION = ON, DEFAULT_DATABASE = Adventureworks2008;

4. Associating Logins with Certificates and Asymmetric Keys

In SQL Server 2008, you can associate SQL Server logins to certificates and asymmetric keys. Mapping a SQL Server user to a certificate or asymmetric key controls the application rights and access levels in SQL Server. We will review certificates and asymmetric keys in detail later on in this chapter. Here we briefly discuss and provide an example of associating users to Certificates and Asymmetric Keys.

You specify the login name that you would like to create, then reference the certificate or asymmetric key that you are associating the user to, and you are all set. Make sure the key or certificate that you are associating the user to resides in the master database. Review the following example of a certificate creation followed by a user that is created using the certificate.

Use master;
GO

CREATE CERTIFICATE apressCert
ENCRYPTION BY PASSWORD = '5qlS3rvErR0cks'
WITH SUBJECT = 'book',
START_DATE = '01/01/2009',
EXPIRY_DATE = '12/31/2010'
GO

CREATE LOGIN apressCertUsr
FROM CERTIFICATE apressCert

5. Linking Credentials to Logins

SQL Server 2008 allows you to create SQL Server logins and associate them to credentials. Credentials contain authentication information for connecting to resources outside of SQL Server. Credentials generally contain Windows username and password information used internally by SQL Server to access an outside resource. You can associate credentials to Windows and SQL Server-authenticated logins; however, the information stored within a credential allows SQL Server-authenticated users to connect to resources outside of SQL Server. Picture this: A user connects to SQL Server using their SQL Server login account, and then they need to perform an action on the server using the credential that they are associated with to access that resource. SQL Server will use the username and password from the credential to fulfill the request. You can map multiple SQL Server logins to the same credential.

In this example, you are going to link a credential to a SQL Server login. Following the syntax in Listing 8-1, you can see that linking a login to a credential is straightforward. The first thing you do is supply the username that you want associated to the credential and the password, and then specify the credential name that you are assigning the user to. (See the following code sample.) The example also shows you how to create a credential.

CREATE CREDENTIAL apressCred
WITH IDENTITY = 'sylvester',
SECRET = 'password'
go

CREATE LOGIN apressCredUsr
WITH PASSWORD = 'P@ssw0rd!',
CREDENTIAL = apressCred
GO

Generally, we recommend that you use Windows authentication because it provides the benefits of user administration and increased security. In most organizations, domain accounts or local server accounts have password policies in place that force users to have strong passwords as well as modify their passwords in a predetermined amount of time. Luckily, if you are unable to use Windows authentication, SQL Server 2008 has the ability to set password expiration and enforce strong passwords for SQL accounts.

Enabling the password enforcement policy adds additional security to SQL Server accounts. Still, we recommend using Windows authentication when possible. Removing additional user account administration from your long list of daily tasks enables you to spend more time doing fun DBA stuff, like tuning queries and solving performance problems. No one enjoys the repetitive task of constantly resetting user passwords.

6. SQL Server-Level Roles

SQL Server 2008 has predefined roles or groups that enable you to manage permissions for SQL Server logins throughout the server. Microsoft defines the server roles, and you cannot create additional roles beyond what Microsoft has defined. Logins added to sever-level roles have the ability to add or delete other users from the role. The available server-level roles are as follows:

• SysAdmin: Allows users to perform any activity on the server.

• ServerAdmin: Permits users to manage configuration options on the server and shut down SQL Server.

• SecurityAdmin: Gives users the ability to grant, revoke, and deny server- and database-level permissions. They can also manage users and passwords, as well as reset passwords of other users.

• ProcessAdmin: Allows users to end processes running on an instance.

• SetupAdmin: Creates linked servers.

• BulkAdmin: Performs bulk-insert statements.

• DiskAdmin: Manages the disk files.

• DBCreator: Creates, alters, or drops any databases.

• Public: The default role that server logins belong to.

6.1. Adding Logins to Server-Level Roles

In T-SQL, adding logins to server-level roles occurs via a stored procedure sp_addsrvrolemember. The stored procedure expects two parameters: a login name for the user that you want added to the role and the name of the role. Try the following code sample to add a login to a server-level role.

EXEC master..sp_addsrvrolemember @loginame = N'apressSecurity',_
 @rolename = N'serveradmin'
GO
EXEC master..sp_addsrvrolemember @loginame = N'apressSecurity', _
@rolename = N'securityadmin'
GO
EXEC master..sp_addsrvrolemember @loginame = N'apressSecurity',_
 @rolename = N'processadmin'
GO
EXEC master..sp_addsrvrolemember @loginame = N'apressSecurity',_
 @rolename = N'dbCreator'
GO

6.2. Removing Logins from Server-Level Roles

In T-SQL, removing logins from server-level roles also occur via a stored procedure sp_dropsrvrolemember. The stored procedure also takes two parameters; a login name that you want removed from the server-level role and the role name that you want to remove the login name from.